Technically speaking, any part of argv0 may be quoted. E.g. C:\"path to"\"py.exe" is parsed as C:\path to\py.exe by the crt. Being quoted just prevents tab or space from terminating the argument.

Please see the associated bug (which I just fixed, because I put the wrong ID in the title originally).

We're following CreateProcess rules here, because it's going to be passed to CreateProcess.

@ChrisDenton, The C runtime's more general parsing of argv[0] (i.e. multiple quoted parts terminated by space or tab) is only relevant if the executable path is passed explicitly to CreateProcessW() in lpApplicationName. If CreateProcessW() is called with lpApplicationName as NULL, as the launcher does, then the API parses the command to run from lpCommandLine. If the command line begins with a double quote, the API consumes all characters up to the next double quote or the end of the command line. If the command line doesn't begin with a double quote, the API tokenizes on space and tab characters, repeatedly searching until it finds a non-directory file.

For example, if the command line is r'C:\Program Files\Python311\python.exe', the API will execute "C:\Program.exe" if it exists. If the command line is r'"C:\Program Files\Python311\python.exe"spam', the API will execute "C:\Program Files\Python311\python.exe" if it exists. Note that there's an inconsistency with the C runtime's quoting rules. The CRT always splits arguments on an unquoted space or tab. For example:

>>> script = 'import sys; print(sys.orig_argv)'
>>> subprocess.call(fr'"{sys.executable}"spam -c "{script}"')
['C:\\Program Files\\Python311\\python.exespam', '-c', 'import sys; print(sys.orig_argv)']
0

The API executed "python.exe", not "python.exespam".

Yes, that inconsistency is what worried me. As far as I understand it, no normalization is being performed in the python code so the inconsistency remains? So the CRT and CreateProcessW will be understanding the arguments differently?